1. Field of the Invention
The present invention generally relates to collaboration systems implemented on networked computers and, more particularly, to a method for building a locking, migration, dynamic clients, and dynamic partitions capable distributed server for a real-time collaboration session.
2. Background Description
Software for collaborative work, i.e., work involving many users and/or agents falls into two categories of use. One is termed asynchronous collaboration and the other, synchronous collaboration. Examples of software for asynchronous collaboration are groupware such as Lotus Notes and Microsoft Exchange. These along with other examples, such as discussion groups where data is changed batchwise, have the characteristic that neither do they require, nor do they particularly cater to the concurrent presence of many users and agents in the work environment. Work environment can include all users and agents that use computers that are connected to each other by networks such as Internet or intranets.
In contrast to software for asynchronous collaboration, software for synchronous collaboration is designed to cater to concurrent users and agents. It includes collaboration tools such as chat, concurrent whiteboards and the more sophisticated SameTime environment. These tools provide for real-time interaction among groups using the same shared workspace. Whatever be the workspacexe2x80x94document, spreadsheet, Computer Assisted Design (CAD) drawing, etc.xe2x80x94it can be seen and modified by the collaborators, simultaneously. Modifications to the workspace are made available to all group members, immediately and synchronously.
Synchrony in multiple updates made by collaboration participants has to be ensured by the underlying synchronous collaboration implementation. One of the common ways by which this is done currently is by the inclusion of a centralized server. A centralized server is a software process running on one host machine(a hardware computer) that introduces a serialization order among multiple modifications. Thus multiple, simultaneous updates to a shared workspace are communicated to the server which converts them into a sequential stream of updates to the workspace. The stream of updates is then reflected back to all participants, each of whom is assumed to be running a software process, a client, in order to interact with the workspace. Each participant or client thus sees the shared workspace develop in an identical mannerxe2x80x94starting from the same initial state and changing under the same stream of updatesxe2x80x94as any other participant or client of the collaboration. This method of streaming updates has many parameters. Each parameter can lead to a different behavior of collaboration at the user level.
Examples of parameters are: What is a modification? Is it a sequence of user-level operations and/or some translation of the same? Is it the complete, changed workspace itself? Is it an object differencexe2x80x94changed workspace minus unchanged workspace? What is the role of history of serialization in serialization itself? Is there any role? Can users explicitly lock out other users while making changes to the shared workspace? Answers to each of these questions can affect what the collaboration implementation means to its users, or in other words be a different definition of synchronous collaboration. Yet what all of these implementations have in common is their dependence on one server process to make serialization decisions for them.
As collaboration needs scale upxe2x80x94number of clients changing the workspace and needing synchronous views of the workspace goes upxe2x80x94the single server process running on a single machine and the communication network bringing about communication between the server and the clients can become severely loaded with computation and communication requirements. Indeed since the architecture of the collaboration implementation is such that it focuses all communication to one point in the communication network, namely the server""s machine, it leads to the development of an unbalanced load on the communication network. It is possible that the communication network cannot effectively service the xe2x80x9chot spotxe2x80x9d of communication, viz., the server""s machine, despite being relatively lightly loaded in other parts of network or on the average. The result can be unacceptable delays and degradation in performance from the perspective of collaboration participants.
The invention disclosed in application Ser. No. 09/241,991 addresses the above issue by breaking the notion of one, centralized, software, server process into multiple, independently-communicating, asynchronous, independent, distributed software processes. Multiple software processes make up a distributed server, as shown in FIG. 2 of application Ser. No. 09/241,991. A distributed server is capable of being distributed and executed upon multiple heterogeneous hardware/software platforms that comprise the network and front ends participating in a collaboration session. The distributed server requires a partitioning of the shared workspace to be available in order to be applicable. The multiple software processes of the distributed server can be distributed to different machines and can be run simultaneously on the different machines. Thus, the distributed sever architecture can avoid focusing all communication to one point in the communication network, and diffuse away the xe2x80x9chot spotxe2x80x9d of the centralized server into different parts of the network.
The distributed server in application Ser. No. 09/241,991 does not support migration of its processes, does not support locking of partitions by a client for exclusive use, and is limited to a static definition of workspace partitions and collaboration clients. In other words, in the distributed server of application Ser. No. 09/241,991, no new partitions can be created in an ongoing collaboration session, no old partitions can be deleted at run-time, no client can leave an ongoing collaboration session, and no client can join or rejoin an ongoing collaboration session. All of these limitations are addressed by this invention whereby the distributed server of application Ser. No. 09/241,991 is extended to become capable of fully handling dynamic clients, dynamic workspace partitions, locking and migration of distributed server processes while retaining the capability of fully handling static clients and static workspace partitions. As described in this disclosure, if the partitioning made available to a distributed server is dynamic, then processes corresponding to dynamic partitions can be started/ended/converted dynamically. In a collaboration session with dynamic clients, any client can leave or join the collaboration session at any time provided that the session has at least one client present at any time. The one client can be a different client at different times - in other words, one client can pass the xe2x80x9cbatonxe2x80x9d to another; however, at any time, there has to be at least one client present in a collaboration session. This is a natural requirement for a collaboration session, since at least one person/client has to be present in order for even a rudimentary form of the session to take place.
It is therefore an object of the present invention to provide a method for building a locking, migration, dynamic clients, and dynamic partitions capable distributed server for a real-time collaboration session.
In order to take into account the changing nature of the communication network, wherein machines can be added, loaded, and removed dynamically, the processes of the distributed server can be migrated from machine to machine, dynamically. Indeed, the distributed server processes can avoid dedicated server hosting machines by residing and running solely on the machines hosting the client processes. In this case, the distributed server processes can migrate as and when new client machines are added or removed. The extended distributed server supports locking a partition by a client whereby the client with a lock can modify the locked partition until the client releases the lock.
According to the invention, there is provided a method for building a distributed server capable of handling locking, migration, dynamic clients, and dynamic partitions for a real-time collaboration session. The method includes: (i) a method by which a collaboration front end or client can synchronously create some new partitions; (ii) a method by which a client can synchronously delete some existing partitions; (iii) a method by which a client can synchronously get permission for creating or deleting partitions; (iv) an optional method based on optional, application-supplied creation/deletion server that is an alternative for the method for getting permissions; (v) a method based on history servers for providing a history of modifications so that a newly-added client can compute the current state of a shared workspace; (vi) caching or granularizing of intermediate modification sequences by the aforesaid history servers so that computation space and time are reduced; (vii) a method each for migrating partition server(s), history server(s), a creation/deletion server, and a collaboration server; (viii) a method for locking partition(s) and unlocking partition(s) whereby partition servers can handle lock and unlock operations; (ix) an extension of the preceding method of locking and unlocking partition(s) to accept pre-announced creation and deletion of partition(s); and (x) a method for carrying out advanced dynamic-partitioning activities like splitting a partition, merging partitions, shifting data from partition to partitionxe2x80x94these activities are carried out naturally by locking the concerned partitions during the process of execution.
With respect to the distributed server in application Ser. No. 09/241,991, these methods preserve: (a) generalityxe2x80x94different definitions of a modification continue to be supported along with additional support for a locking capability; (b) extensibilityxe2x80x94simple, comprehensive and easy-to-implement inter-partition synchronisation is provided; (c) generality for partition hierarchies and groups, wherein in addition to the capabilities in the distributed server disclosed in application Ser. No. 09/241,991, simultaneous or incremental creation or deletion, of any group of new or existing partitions is also supported (as applicable). In comparison to the centralized server and the distributed server disclosed in application Ser. No. 09/241,991, these methods further improve interoperability across heterogeneous software/hardware platforms by (a) extending the functionality of distributed-server-based real-time collaboration to dynamic partitions and dynamic clients, and (b) allowing the distributed server processes to migrate and dynamically adapt to changing network (including frontends), and collaboration conditions, which in turn obviates the need for special support for immobile processes from the (hardware/software platforms/servers comprising the) network in the face of commonplace faults, transients, load relief, and balanced/unbalanced development of network load.